IBIS Macromodel Task Group

Meeting date: 20 May 2014

Members (asterisk for those attending):
Agilent:                      Fangyi Rao
                            * Radek Biernacki
Altera:                       David Banas
ANSYS:                      * Dan Dvorscak
                            * Curtis Clark
Avago (LSI)                 * Xingdong Dai
Cadence Design Systems:     * Ambrish Varma
                              Brad Brim
                            * Kumar Keshavan
                            * Ken Willis
			    * Scott Huss
Ericsson:                     Anders Ekholm
Intel:                      * Michael Mirmak
Maxim Integrated Products:    Hassan Rafat
Mentor Graphics:            * John Angulo
                            * Arpad Muranyi
Micron Technology:          * Randy Wolff
                              Justin Butterfield
QLogic Corp.                  James Zhou
                              Andy Joy
SiSoft:                     * Walter Katz
                            * Todd Westerhoff
                            * Mike LaBonte
Teraspeed Consulting Group:   Scott McMorrow
                            * Bob Ross
Texas Instruments           * Alfred Chong

The meeting was led by Arpad Muranyi.

------------------------------------------------------------------------
Opens:

- Arpad: I sent personal invitations to IC vendors to join us today.

- Michael M: The DAC IBIS summit will be June 5.
  - We have room for more presentations and sponsors.

--------------------------
Call for patent disclosure:

- None

-------------
Review of ARs:

- None

-------------
New Discussion:

SPI summit last week in Europe:
- Randy: There were mostly SPI attendees, many familiar faces.
  - Wael Dghais gave a presentation on alternate IBIS algorithms.
    - This is a common theme for European summits.
    - Wael has presented on this before.
    - It has Y/Z and Q/Z tables, extracts from S-parameters.
    - He would like to know if IBIS is interested in this.
    - His paper will be on the IBIS website.
  - They look forward to regular IBIS specification releases.


Backchannel proposals:
- Arpad: There was a motion last week to decide between BIRD 147 and Walter's proposal.
  - We can have more discussion first.

- David: Walter's proposal is rigid in the manner that a TX describes its capabilities.
  - BIRD 147 protects me from being tied to that.
- Walter: Most TX models have some number of pre and post taps with coefficient ranges.
  - Training protocols either increment, decrement, or set tap coefficients.
  - Any existing TX that has those can be trained without knowing the protocol.
  - If it doesn't have those things it probably is not trainable.

- David: On Walter's slide 8 it says taps maintain peak-to-peak voltage.
  - We may not want to take away the freedom to meet that in different manners.
  - This proposal wants to send commands to change Vod.
  - I would have to re-architect my models to handle this.
- Walter: You would expose your taps to be adjustable.
  - The model itself maintains peak-to-peak voltage.
  - The sum is always one and taps are adjusted accordingly.
- David: We divide analog and EQ behaviors.
  - It could be a problem if the model was told to change analog behavior.
- Todd: The model must produce a physically realizable output.
- David: Will the EDA tool be "too helpful" and make changes for me?
- Walter: The TX can refuse to make some requested changes.
  - It will tell the RX what it really did.
- David: Then my TX is at the mercy of the EDA tool, changing my Vod.
- Walter: Some existing models will change peak-to-peak voltage as you change taps.

- David: I had claimed the Cadence proposal has extra indirection, is that true?
  - Will BIRD 147 protect from this?
- Ambrish: Our entire job is to open a channel for TX/RX communication.
  - The EDA tool does not get in between the TX and RX.
- David: So the TX will have to be modified?
- Ambrish: Yes it must be a black box.
- Walter: Then you are at the mercy of the RX.
- Kumar: It is not the tool's business to know the architecture.
- Ambrish: The TX may ignore tap change suggestions.
- Kumar: A robust RX will not assume the TX has done something.
  - It must analyze the waveform.

Arpad showed Walter's presentation:
- Alfred: The MAC layer has to establish communication.
  - The IP vendor decides how to achieve desired voltage output.
  - An ordinary TX can probably do this.
  - We should not need a BCI file, but that would be OK.
  - In link training the RX must reach steady state.
  - That can take very long, will we still use Ignore_Bits?
  - Frame markers are needed to separate training phases.
  - It would be overkill to implement that though.
  - Link training is proprietary.
  - The communication may help to guess the algorithm.
  - We have to address presets, Walter's proposal has that.
  - For statistical most settings are digital, we don't need to identify coefficients.
  - The Cadence proposal is not clear about that.
- Ambrish: The BCI file standardizes the process.
  - You can have proprietary training.
  - The BCI file can capture it.
- Arpad: The question of Ignore_Bits is interesting.
- Ambrish: The BIRD mentions that.
- Walter: The Cadence approach is limited to solving how well the RX trains the TX.
  - Another problem is finding what the optimal tap coefficients are without running the training algorithm.
  - The RX can say the exact tap coefficients it wants.
  - Another way is to increment and decrement.
  - Proprietary training may be entirely inside the RX.
  - You can set registers and not be constrained by any protocol.
  - Ignore_Bits is up to the RX, it decides when to set coefficients.
- Ambrish: That is covered in BIRD 147 page 9.
- Walter: Cadence proposed a complicated training pattern syntax, is that necessary?
  - Would PRBS11, PRBS17 be sufficient?
- Alfred: The pattern is usually PRBS11 for KR.
  - PRBS31 can be a replacement for the pattern for PCIe .
  - Finding the optimal operating point would be very useful.
  - Will there be enough time in training to adapt to minor changes?
  - Making the wrong changes can mess up the CDR.
  - It would help to reset to initial settings.
- Walter: Both proposals would allow the RX to reset the TX and reset or not reset DFE settings.
- Todd: BIRD 147 page 9 does not allowing for settling the RX after training.
- Mike L: There could be multiple BCI files for any protocol.
- Ambrish: We would work that out and settle on one.

- Bob: We haven't worked out what to do about a parser for BCI files.
  - With Walter's proposal would the protocol be in the RX AMI file?
- Walter: Only special text strings to pass back and forth would need anything in AMI.
- Ambrish: How would you accommodate multiple protocols in one model?
- Walter: With a protocol name parameter.
  - To be correct even LFSR can't describe everything.

- Arpad motioned to table the vote for today,until the next meeting.
- David seconded.
- No one objected.

- Scott: It would not be appropriate to use standard PRBS23 for PCIe.
  - Can the TX communication rejections back to the RX?
  - Are limits confined to a single tap or are they multi-dimensional?
- David: They almost always depend on amplitude.
- Scott: The RX may not know why the TX reached a limit, and that matters.
- David: Cadence proposes the RX would keep trying and eventually give up.
- Walter: Both proposals address this.
  - The RX receives info on what the TX actually did.
  - Specific bit patterns might have to be a file of zeros and ones.
  - It might be scrambled, for exampled.
  - TX taps can have coefficients not allowed for current conditions.
  - This should be in the TX DLL.
- Arpad: Resolve might be able to help.
- Walter: That may be complex.
- Scott: Could have have equations to define tap limits?
- Walter: That can be complex, difficult to put in a protocol.
- Michael M: Are there constraints on indexes?
- Scott: There are not hard limits on each tap.
- Michael M: The endpoints are integers, not float.
- Walter: The coefficients really are a poor man's floating point number.
- Michael M: The conversions back and forth are critical.
  - There can be quantization error.

-------------
Next meeting: 13 May 2014 12:00pm PT

-------------
IBIS Interconnect SPICE Wish List:

1) Simulator directives
